On Fri, 26 Feb 1999 21:17:12 +0100, Rudy Velthuis <rve### [at] gmxnet> wrote:
>There are many keywords in POV-Ray which are in fact just representations of
>a numeric, like
>prism's linear_spline, quadratic_spline, cubic_spline, bezier_spline,
>linear_sweep and conic_sweep. They are in fact just numerics which were
>given a name. In my concept they would be constants or enumeration types,
>which (jn this case) represent numbers. It would have done, if the creators
>of POV had #declared these words as numerics and had made the PRISM_ITEM
>property of a prism a numeric:
>
>#declare linear_spline = 1
>#declare quadratic_spline = 2
>...

In fact, if you look in the appropriate places, you'll find that some of
the radiosity constants are declared just this way, so it will work in a
limited sense.  But the reason for the keywords is that they can be 
specified in any order, or not at all.  Consider, say, the smooth keyword
in a height_field object.  If we instead had
#declare smooth=1; #declare no_smooth=0;
then we would always have to specify either smooth or no_smooth.  And
because they lack any type information, we'd have to be very careful to
specify it in just the right order.  I don't know about you, but I already
get confused about order on some of the more complicated object types such
as bicubic patches. I'd almost rather see a sphere, say, have keywords for 
radius and center as well and make all the parameters optional (but 
defaulted) so I could say:

// a sphere centered on zero with unit radius:
sphere {}
// a sphere centered on zero with radius 2:
sphere {radius 2}
// a sphere centered on MyVect with unit radius:
sphere {center MyVect}

This is actually pretty close to what you're proposing, I think, and could
perhaps even be made backward-compatible, but I think it would have an adverse 
effect on parse time.

I guess what I don't understand is why you ever need camera.lookat.  Consider:

Your way:

  #declare MyCamera=camera {
    location -20*z
    look_at Complex_Slow_Macro_Expression( foo, bar, baz )
  } 

  camera{ MyCamera }
  sphere { MyCamera.look_at, 1 texture {pigment {color red 1}}}

My way:

  #declare camera_look_at=Complex_Slow_Macro_Expression( foo, bar, baz );
  camera {
    location -20*z
    look_at camera_look_at
  } 

  sphere { camera_look_at, 1 texture {pigment {color red 1}}}

I took some liberties with your way to deal with my opinion that there
shouldn't be any serious order dependencies within the scene description.
That is, the declaration of your sphere shouldn't be dependent on the
declaration of your camera having happened first.

I just don't understand why, if you know you're going to need it, you 
wouldn't just #declare the look_at position and use that when you need
it, especially since the alternative is to #declare the camera if you're 
going to look at its members (I can't conceive of any usable syntax for 
looking at the members of anonymous scene elements.)

And if everyone would just adhere to the simple rule that keywords should
be all lowercase and identifiers shouldn't, there would never be any
collisions.  Perhaps there should be a warning (disabled by #version,
of course) if you #declare something with an all-lowercase name.

Post a reply to this message